[技术|Inceptor任务的图形化分析（一）](https://ask.hellobi.com/blog/transwarp/5748)

技术|Inceptor任务的图形化分析（一）

发表: 2016-12-22 浏览: 785

大数据

了解执行机器的运行情况对于性能调优、执行过程的问题排查十分重要。为方便对执行情况的监控，Inceptor专门提供了管理界面（4040端口），用于给用户查看系统性能和各机器各进程对各任务的执行情况。

为达到有效分析语句执行过程的目的，在浏览管理界面时，我们应该将重点放在以下这些环节：检查执行耗时，报错，查看所有Executor是否已正常启动、Executor ID号是否连续、配置是否生效等。本系列文章将针对这些项目，介绍Inceptor管理界面上各目录、标签与标题的代表含义，以及如何通过阅读各属相指标值，来判断系统的工作情况。

Inceptor管理界面端顶部提供了七个标签页：Jobs、Cluster、Local、Storage、Holodesk、Environment、Executors。如下图所示：

​

我们将分别介绍这七个标签页的使用和浏览方式。由于本次内容篇幅较多，因此分为多篇文章展开。本文将首先介绍Jobs和Cluster两个标签页，剩余标签页以及相关内容会在今后陆续提供。

Jobs和Cluster界面提供了在集群模式下执行的所有Job和Task的信息，使用频率较高，是进行管理监测时应注意关注的页面对象。

Cluster

首先来看Cluster标签页。Cluster页显示了所有在Cluster模式下执行的SQL语句的实现过程与相关信息。

在Cluster模式下，每条语句的实现过程被分为了一个或者多个Stage，Stage是一个基本的执行单元，它又由多个Task构成。所以我们在Cluster页面上看到的都是各个Stage及其所包含的Task的信息。

Cluster页是对各Stage运行情况的宏观描述，描述内容主要涵盖了以下9个基本信息：

Stage的类型有三种：Active Stages、Completed Stages、Failed Stages。分别显示在Clusters页面的头部中部与尾部三个板块，对应的含义分别如下：

• Active Stages

提供正在运行的Stage信息。执行SQL时，如果某个Active Stage的耗时较长，可以进入Description中所提供的链接查看Stage的具体细节。

下面是一个Active Stage描述信息的示例：

从该图可以发现，Active Stage中成功Task数量和总数量是不相等的；而且在实际应用中我们会看到Active Stage的状态是处于实时变化中的。

该板块中，我们还可以通过”(kill)”按钮直接kill掉正在执行的Stage。

• Completed Stages

包含所有已完成的SQL语句的Stage信息。与Active Stage相同，此类Stage提供除了失败原因（Failure Reason）之外的所有基本描述信息，但不同的是Completed Stage的各信息状态是稳定的，而且成功Task数量总是等于总数目。

另外该列表还会提供实现该SQL语句所经过的Stage的总数量。

下面示例图提供了某条SQL语句所有Completed Stage的基本信息：

从上图可以看到，当前观察的这条语句被分为了4个Stage执行，每个Stage按照实现由先到后的实现顺序从下到上依次排列，即最上面的Stage是最新的，底部是最先完成的。

还可以发现，Task ID 号为7002和7003的Stage的Shuffle读和写的数据量分别为268.0B和538.0B，通过Shuffle Read和Shuffle Write的大小，用户可以获知Shuffle的数据量，从而判断当前的Shuffle是否给内存造成过大压力。

• Failed Stages

记录了所有执行失败的Stage的信息。对于此类Stage，管理界面会在Failure Reason一栏中给出具体的失败原因，此列内容很重要，对于问题分析和解决报错有很高的信息价值，当执行失败使请读者对此内容重点分析。

Failed Stage的信息显示结果示例如下：

从提供的失败原因可以知道该Stage的失败是因为ID为4300的Stage被kill掉，而导致后续相关Task都无法执行。

除了以上三种Stage的信息描述，Cluster页面还在页面左上角分别给出了这三类Stage的当前数量。如下图所示：

管理界面还可供查看每个Stage的工作内容、各个Task的执行时间、时间的统计信息、从属的Executor等Stage内部详细信息，以及不同Executor中Task的执行情况。呈现这类信息的页面链接提供于Cluster标签页的Description栏。此部分内容将在后面的文章中具体介绍。

Jobs

Jobs页面反馈了各个Job的执行信息与运行情况。每个Job由Stage构成。页面上对各Job的描述信息包括以下六个方面：Job Id、Description、Submitted、Duration、Stages:Succeeded/Total、Tasks(for all stages): Succeeded/Total。它们的代表含义和对Stage的描述信息一致，只不过是对整体Job的描述。

其中“Stages:Succeeded/Total”表示了该Job中成功执行的和全部Stage的数量；“Tasks(for all stages): Succeeded/Total”表示了该Job包含的所有成功的和总的Task数量。

通过点击Description中的链接进入Job的详细信息显示界面，可看到从属于此Jobs的所有Stage的信息。

进入该页面后，用户还可通过位于该页面左上角的DAG Visualization按钮获得当前Job的DAG。

DAG是表达各个RDD之间转换的关系的有向无环图，图形化的描述了各个操作符之间的传递顺序，直观的反映了Job执行的全过程。我们可以通过分析DAG，明确每一个Stage的任务内容，对于复杂的语句可以帮助锁定到出现性能问题的环节。

例如，对于如下语句：

该语句的内容可以大致分为三部分：第一个WITH-AS语句中的store_sales和date_dim的JOIN；第二个WITH-AS语句中的catalog_sales和date_dim的JOIN；两个WITH-AS短语的JOIN和聚合函数计算。

通过在管理界面上会观察发现该语句的执行被分为了两个Job。第一个Job负责扫描date_dim的数据，并结果放在HDFS上，为MapJoin准备。第二个Job负责了主要的工作，工作量较大，涉及的转换较多，过程较复杂，所以我们来对它的DAG进行分析，来看它的逻辑顺序是否是满足语句的实现需求。上述语句对应的DAG在管理界面上如下所示：

由图所示，该语句分为六个Stage执行。Stage ID号从2861开始分配至2866。每个Stage的内部由蓝色矩形纵向排列，表示该Stage内的RDD操作，操作名称显示在框内。箭头表示了RDD的转换走向。

由图可知，该Job从Stage 7865开始扫描过滤store_sales，接着和date_dim进行MapJoin，然后再通过Stage 7866在过滤catalog_sales后执行过滤结果集和date_dim的MapJoin。

接着Stage 7867和7868分别对这两个JOIN的结果Reduce，并把输出交给Stage 7869执行Common Join，最终Stage 7864又执行了一次Reduce并输出结果。

这样的执行顺序是完全符合语句的实现逻辑的。同理，读者可以借助界面提供的DAG去理解更复杂的SQL的实现过程，有效判断哪些环节出现了问题、哪些部分需要优化。

Jobs页面也根据Job的类型（Active Jobs、Completed Jobs、Failed Jobs）分别放在三个板块，分别提供正在执行的、已完成的、失败的Jobs信息。

使用总结

本文对Inceptor管理界面中的Jobs和Cluster两个标签页进行了简单介绍，分别简析了这两个页面上的字段信息含义。

在观察Cluster页面时，我们通常建议关注Stage的执行时间是否太长，失败Stage的数量是否过多，失败的原因是什么，每个Stage的Task总数是否过多或者过少以及成功Task的数量是否过少，Shuffle Read/Write的数据量是否过多。

类似的，在观察Jobs页面时，我们应观察Job的执行时间，失败Job的数量是否过多，失败Job中的失败Stage和失败Task的数量。另外，有了DAG的帮助，我们还可以理解Job的实现流程，Stage的工作内容，将成功和失败的Stage分别对应至具体的操作符。

在实际使用时，除了需要理解页面上各个字段所代表的含义，读者还应该分析出这些指标的高低所反馈的信息。我们会在今后的文章，结合后续内容，介绍如何根据这些指标数值提取信息进行性能优化。

技术|Inceptor任务的图形化分析（二）

发表: 2016-12-29 浏览: 959

大数据

Inceptor管理界面端顶部提供了七个标签页：Jobs、Cluster、Local、Storage、Holodesk、Environment、Executors。上一篇文章中已介绍了Jobs和Cluster两个标签页的使用和浏览方式，本文将衔接上篇文章对剩余5个标签页的使用和浏览方式进行介绍。

这五个页面中，Local、Holodesk和Executor三个页面较常使用。其中，Local页显示了Local模式下执行的所有SQL语句的相关信息，Holodesk页面提供了各个内存表信息，Executors页面显示着包含了各个Executor的信息的列表，均是对任务执行状态进行管理监测时应注意关注的页面对象。而Storage Environment的使用频率相较而言不高，Environment通常用于帮助纠错调优。

Local

和Cluster标签页相同，Local页也在左上角记录了各类Stage数量。

例如，某集群当前各类Stage数量情况、Active Stages、Completed Stages与Failed Stages的信息在Local页的界面如下图所示。

该页面显示此集群目前有三个Completed Stages，Active Stage和Failed Stage的数量为零。

Storage

Storage页存储着内存表信息，但目前已基本废除。因而这里不再详叙。

Holodesk

Holodesk页面提供了关于各个Holodesk内存表的信息。其描述内容有三方面：Table Name、Block Number、Total Size，分别表示表名、表被分为多少块文件存储和表的总大小。在点击Holodesk按钮后会进入如下所示界面：

​

进入表的链接后可以看到对应表的各个Block的存放位置和大小。例如，点击进入第二行tpcds_holodesk_2.customer_address表的信息描述界面，如下图所示：

该页面提供了该表的名称，以及分别包含该表相关Host和Block信息的两张列表。第一个列表名称为Host Information，记录了表内数据分布在哪些机器上，每台机器上存放的Block数量及大小。第二个列表为TableInfo，记录了该表被划分为的Block名称和分别所在的Host以及规格大小。

读者可以依据该页面的信息来判断Block的划分是否均匀，存放节点的分布是否合适，从而对文件的大小和分布方式进行调节。例如，如果同属一张Holodesk表的Block之间如果大小相差悬殊，就说明存在数据倾斜，此时需要靠一些手段（如分桶）使数据分布均匀。

Environment

Environment页记录着环境配置信息，在需要进行环境检查的必要情况下，用户可以通过它获取有效信息。读者可自行登录到该页面观察所需内容。这里不再详叙。

Executors

Executors页面显示了集群中各个Executor的信息，这些属性信息通过Executors列表反馈。该列表由以下11个维度构成：

​

例如，某一集群的Executors页面的列表如下图所示：

列表上的信息可用于检查集群上的Executor数量，读者可以通过比较此数量是否和设置相符，来判断集群是否有未启动的Executor。

另外还可以观察Shuffle Read/Write的数量来判断任务量在整个集群的分配是否合理、处理的数据量大小是否合适。

尤其应注意Executor ID值的分配是否有中断。正常情况下，Executor ID包含着从1至n的n个连续整数以及。（代表负责语句编译与任务分配的Master节点）。由于每次Executor重启后都会被分配一个新的Executor ID，原来的号码会从列表上消失，所以如果ExecutorID除之外的值出现断号，就说明位于断点的Executor发生过退出和启动（可能是由GC引发）。如果重启次数过多，有必要对性能和业务执行分析，例如检查内存是否溢出、磁盘是否不足、是否有宕机现象。

使用总结

本文对Inceptor管理界面中的Local、Holodesk、Executors以及Environment、Storage五个页面进行了介绍，其中着重介绍了前三个标签页。

学会阅读并分析Local、Holodesk、Executors中的信息对于任务的优化将会有很大帮助。

实际应用过程中，在浏览Local页面时，我们需要了解Local模式下任务的执行情况，利用Scan的数值量判断当前索引对于执行的任务而言是否建立于合理字段。

在观察Holodesk页面时，要注意数据的分布，尽量保证各个Block有合适的数据量，划分均匀，避免数据倾斜。

在观察Executors页面时，首先应注意Executor是否都已正常启动，其次Shuffle的压力是否过大，最后分析Executor ID是否有断号，是哪个Executor导致的断号。

这三个页面为使用者提供了关于Local模式任务、Holodesk数据分布、Executor对象的相关信息，这些信息虽然基础，但有时能起到十分关键的指导作用。由于这些页面中存在的异常往往能够折射失败任务的本因，希望读者能够通过本文掌握对它们的分析方法，及时发现异常，作出应对措施。

技术|Inceptor任务的图形化分析（三）

发表: 2017-01-03 浏览: 954

大数据

如前两篇文章介绍的，在Inceptor中，Jobs被划分为Stage执行，每个Stage由多个Task在不同Executor上实现，以处理存储位于不同节点的数据。Jobs、Stage、Executor以及关于存储的标签页分析方法已经提供于之前两篇文章，本文将介绍如何观察指定Stage中的Task信息，该信息页面通过点击Cluster标签页中相关Stage的链接进入（如下所示），我们称之为Stage信息页面。

Stage信息页面包含了三种信息列表Stage Summary Metrics、Aggregated Metrics by Executor、Tasks，以及DAG Visualization和Event Time两个图形化反馈信息。下面是对它们的具体介绍。

Stage的信息列表

• Summary Metrics for N Completed Tasks

该列表反映了Stage中N个已完成的Tasks的统计分析信息，提供了任务各类开销的整体占用统计分布情况。页面显示如下图所示：

该列表将Task的开销细分为五个方面，通过Metric字段列举这五种开销的名称，由上至下分别为：结果序列化时间、总执行时间、结果获取时间、延时、Shuffle写的数据量。Min、25th percentile、Median、75th percentile和Max分别表示当把所有Task的对应开销看做集合时，该集合元素按从小到大排列后的最小值、1/4处的值、中位数、3/4处的值、最大值，从而获得各Task的各方面开销集中在哪一区间和跨度情况。

• Aggregated Metrics by Executor

该列表的示例如下图所示：

该表中的各字段含义和字面意思一致，除去同Shuffle Spill相关的两列，其余列的含义和已介绍的Executors列表中列值代表意义相同（参考技术|Inceptor任务的图形化分析（二））。Shuffle Spill(Memory)和Shuffle Spill(Disk)分别代表在实现Shuffle时中写入内存和硬盘的数据量，对调优帮助不大，读者可以忽略。

• Tasks

Tasks列表的示例如下图所示：

该列表共有14个描述信息，其含义可以从其字面理解：ID表示为该Task分配的唯一ID号；Status表示Task状态；Executor表示该Task的执行位置；Launch Time表示任务的触发时间；Duration为执行时长；Input为读入数据量；Write Time为Shuffle写时间；Shuffle Write为Shuffle写的数据量。这里对Attempt和Locality Level两个指标的含义做特别讲解。

Attempt代表Task重试（Retry）的次数，如果Attempt数值过大则说明Task的可用资源匮乏（很可能是内存）或者待处理的数据过多，难以应对业务需求。

Locality Level表示计算的执行位置和数据存放位置的关系，可能的取值有三个，名称和代表含义见下表：

所以用户应该尽量保证数据被均衡的分布在各个节点，以尽可能的使计算和数据处于同一个节点、同一个JVM中，从而减少数据远距离传输。当各Task的Locality Level取值都为PROCESS_LOCAL时将处于最好状态。

另外观察Task的Duration情况也可以了解是否存在数据倾斜现象。如果个别Task的执行时长远远大于其余Tasks，即表明数据出现倾斜，应该及时进行数据均衡分配。特别的，如果所有耗时长的Task基本都聚集在一个Executor或一台机器上，说明该Executor或者这台机器出现了问题，需要针对性的排查。

Stage页面的按钮

Stage信息页面左上方有两个用于显示图形描述信息的按钮，分别是DAG Visualization和Event Timeline。

• DAG Visualization

点击该按钮将获得关于当前Stage的有向无环图（DAG），该DAG和Jobs页的DAG显示方式相同，只是这里是对单个Stage过程的图形化描述，提供了在该Stage中各Operator的执行顺序和关系。

• Event Timeline

Event Timeline给出了各Executor的运行开销分布图，如下图所示。

其中每一个横向柱状表示一个Task的执行时间，同一个Executor执行的Task在同一个单元显示。柱型中的不同颜色表示不同类型任务的时长，因此从该图中我们可以发现计算时长（绿色部分）通常占据最大比重。

该图和Summary Metrics类似，反映了Stage中任务执行情况的统计信息，但是是更加直观的表达。

总结

本文对Stage信息页面中的Summary Metric、Aggregate Metrics by Executor、Tasks三个信息列表各列的内容含义进行了解释，并介绍了DAG Visualization和Event Timeline两个图形信息。

其中，Summary Metrics列表通过将Task的整体开销细分为五种，以使用户了解Task的开销具体消耗在哪个环节，以及Task的开销分布从这五个指标上看是否均衡。例如，如果读者发现该列表的Duration行中Max的值远远高于其他几列的数值，那么就说明其中有一个Task的耗时过长，应定位至相关节点检查数据分布以及资源使用情况。

Aggregated Metrics by Executor提供了关于Executor的执行信息。观察该页面时应确保每个Executor都有任务跑，且每个Executor分配的Task数量差距不宜过大。

在浏览Tasks列表时，除了应注意Task的运行时长、GC压力以及Shuffle写的数据量之外，还应该特别关注Attempt和Locality Level两个指标。

最后还可以利用DAG Visualization和Event Timeline这两个图表能来辅助我们对Stage的执行过程及其开销的分布进行更加直观的了解和把控。

Inceptor的图形化页面是重要的分析辅助工具，将这三篇文章介绍的标签页的信息进行结合分析，用户可以从多个维度，多个方向，不同粒度的了解集群任务的处理状态。我们在这三篇文章中对不同指标的异常状态情况进行说明，为的是帮助用户通过指标数值的表象分析出问题出现的本因，如果能利用这一点采取相应措施，将能较快的提升运行与查错效率。

TDH 5.0及之后版本页面

星环计划在TDH 5.0推出新版本页面，新页面的浏览效果更好，速度更快，更方便于观察分析。在这里我们对5.0的Inceptor分析页面做一个小型的预告~~

分析界面的更新和提升主要在以下三方面进行：

\1. 合并Cluster和Local标签页

将Cluster和Local两个标签页的信息合并在一个新的名为Stages的标签页中，通过’Cluster’|’Local’按钮进行切换，而且每个Stage信息中增加了‘Stage Mode’一项，用于表示它是在集群还是本地模式下执行，如下图所示：

\2. 不同类型Jobs/Stages的情况分子页显示

旧版本的Jobs和Cluster页面将不同类型（Active、Completed、Failed）的Jobs和Stage统一显示在一个页面，而新版本则将显示在不同子页里，并在子页的Tab名称右侧提供该类Jobs/Stages的数量，如下图所示：

从该图可以知道Completed Stages数量为562个，当前没有Active和Failed Stage。

这种显示方式下，页面的刷新速度更快。

\3. 分页显示Jobs/Stages信息

原来的分析页面是把所有Jobs/Stages信息提供在同一个页面中，当Jobs/Stages的数量过多时使用者要通过不断滚动鼠标的方式阅读页面下面的信息，影响使用感。新版本将提供分页的功能，信息记录拆分到不同页，用户可以通过选择页号选择阅读某页信息。

除了对于Inceptor分析页面的改进，我们在5.0中开发了很多新产品和功能，敬请各位期待TDH 5.0带来的更好使用体验。